Christoph Hormann wrote:
> Wolfgang Wieser wrote:
>> If the POV team fails to include patches proposed this way, I do not
>> feel guilty for that.
>> 
>> Especially note that in most cases I am not providing a "bug report"
>> but actually a "bug fix".
> 
> My advise in hopefully clear words: 
>
I like clear words :)

> if you observe a problem using 
> POV-Ray you should point this out in one of these newsgroups, if
> possible illustrated with reproducible examples.  
>
I did that. 

> If you think you have 
> a solution for the problem you should of course include it as well 
>
In case I have a solution, I include it as well...

> (not 
> as a patch but as an explanation what you think should be changed).
>
...by explaining what should be changed in the code. This is what I 
mean when calling it "patch": Some lines of code context and some 
text which make it clear to the reader what I propose to be changed. 

It it the easiest way and the only one which makes sure that we're 
all talking about the same thing. 

> After others had the opportunity to comment you should post this to
> .bugreports. 
> And even if you think all this is completely unnecessary 
> and have no idea why anyone would make it that complicated it would
> still be a good idea to follow this.
> 
(1) I _did_ post something about the parametric object to bugreports. 
(2) I do not see it as my task to run after people in a way which seems 
    ridiculous to me. It makes the impression that the POV team is not 
    actually interested in improving the code and that it is my task 
    to bring a patch into their code. Well, up to now, I was not this 
    opinion but...

>> Okay, so then please tell me how I could check if the "break;" in
>> the search loop was included from using the binary?
> 
> To make it perfectly clear your analysis of the source code is
> absolutely irrelevant here.  The beta test phase is about finding
> problems in the use of the program.  If you now find a 'problem' in the
> source that does not manifest itself in form of a problem for the user
> of the program it is completely unnecessary to change it. 
>
So it is better to adjust eve candy than to improve the algorithms to 
run faster. I hope some time in future, the POV team will have changed 
their opinion concerning "quality of code". 

> The only 
> problem you as it seems correctly pointed out is the parametric object
> one.  I don't want to speculate why others have not worked on this but
> the fact that the parametric object is classified experimental gives it
> relatively low priority in general.  
>
I think I have a solution here which completely removes the problem. 
Somebody with more clue about the code (does such one exist BTW?) 
should comment on it and I will post it here this night. 

> The other things you write about in 
> this thread you could have perfectly observed and reported during beta
> phase (and even if they are only 'cosmetic' things it would still have
> been good to point them out).
> 
Let's see: 

- IsObjectInCSG(): 
  cannot be detected without looking at the code

- parametric. Okay, we agreed. 

- radial_pattern(): 
  cannot be detected without looking at the code (or at least I would 
  not know how)

- isosurface warning:
  This warning was caused by a scene written by me which rendered
  Schroedinger equation solutions. To render this scene, a patched version 
  of POVRay (with orbit function built-in) was necessary. Hence, I could not 
  test for this one during beta test and relied on Thorsten who sait 
  something like "I'll see if I can come up with a solution" (non-literal). 

- render status line
  I thought this was already known. 

- Total:..
  This is not a bug. I am just wondering...

Wolfgang

Post a reply to this message